Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-036.txt

Text File | 1992-11-18 | 44.9 KB | 1,208 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sun, 29 Mar 92       Volume 1 : Issue 36

Today's Topics:

    Self-checking for virii
    New Trap Patch Questions
    smallest unit of RTF
    AppleTalk Program Question
    Are there any c++ compilers for the Mac?
    Simple Program...help?
    Preference Files/Folders: How to do under 6.x?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Daryl Spitzer)
Subject: Self-checking for virii
Date: 22 Feb 92 01:01:10 GMT
Organization: MIND LINK! - British Columbia, Canada

>                     New Macintosh Virus Discovered
>
> Virus: MBDF A
> Damage: minimal, but see below
> Spread: may be significant
> Systems affected:  Apple Macintosh computers.  The virus spreads on
>                    all types of system except MacPlus systems and
>                    (perhaps) SE systems; it may be present on MacPlus
>                    and SE systems and not spread, however.
>
> ...
>
> Special thanks to the people at Claris who included self-check code
> into their Macintosh software products.  Their foresight resulted in
> an early detection of the virus, and has thus helped the entire Mac
> community.  We strongly encourage other vendors to consider doing the
> same with their products.
> --
> Gene Spafford
> Software Engineering Research Center & Dept. of Computer Sciences
> Purdue University, W. Lafayette IN 47907-1398
> Internet:  [e-mail]   phone:  [phone]

How would one go about writing code in an application that would self-check for
a virus?  I guess one could do a CRC check on the resource fork...and the CRC
could be stored in the data fork (so the CRC wouldn't be included in
itself)...would this work?
--
- -----------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -----------------------------------------------------------------



- -------------------------

From: [e-mail] (Michael Peirce)
Subject:  Self-checking for virii
Date: 22 Feb 92 05:31:11 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Daryl Spitzer) writes:
>
> How would one go about writing code in an application that would self-check for
> a virus?  I guess one could do a CRC check on the resource fork...and the CRC
> could be stored in the data fork (so the CRC wouldn't be included in
> itself)...would this work?

There are a wide variety of techniques.  The key is *not* to copy
someone else's technique.  If people all use the same technique, then
the virus writer will have an easier time programming around it.

That being said, there are a number of general directions that seem
to work well.  Checksum your code (any code resources your program
uses CODE, WDEF, MDEF, etc).  Look for new resources that shouldn't
be there.  Check the size of resources that sould stay constant.

You may not want to perform an extensive check all the time, maybe
check parts at random so they don't slow your startup time too much.
Also maybe perform checks when you have some idle time.

Beyond detecting possible viruses, this can also provide some protection
against your app running when it is damaged in some other way.

--  Michael Peirce         --   [e-mail]
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California USA 95117
--           & Consulting  --   voice: [phone] fax: [phone]
--                         --   AppleLink: peirce & America Online: AFC Peirce



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Self-checking for virii
Date: 22 Feb 92 10:57:16 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ca> [e-mail] (Daryl Spitzer) writes:

   How would one go about writing code in an application that would self-check for
   a virus?  I guess one could do a CRC check on the resource fork...and the CRC
   could be stored in the data fork (so the CRC wouldn't be included in
   itself)...would this work?

Not verbatim, but close, You have to skip the first N bytes
of the resource fork, since they are used for something or
other that may change. N is probably equal to 256 or so.

Another thing to do is to check that Count1ResTypes and
Count1Resources returns the right values, and that your CODE
resources are of the right size.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Self-checking for virii
Organization: CIS Dept., Syracuse University
Date: Sat, 22 Feb 92 13:10:08 EST

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.ca> [e-mail] (Daryl Spitzer) writes:
>
>   How would one go about writing code in an application that would self-check for
>   a virus?  I guess one could do a CRC check on the resource fork...and the CRC
>   could be stored in the data fork (so the CRC wouldn't be included in
>   itself)...would this work?
>
>Not verbatim, but close, You have to skip the first N bytes
>of the resource fork, since they are used for something or
>other that may change. N is probably equal to 256 or so.
>
>Another thing to do is to check that Count1ResTypes and
>Count1Resources returns the right values, and that your CODE
>resources are of the right size.

The only problem with these various techniques is that a *user* may
*legitmately* change resource in order to customize the software.  In
fact, one might legitimately *add* resources.  (An outdated example,
one might add 'mstr', etc. resources to facilitate pulling "puppet
strings" on older applications.  If these old apps had done such
virus checking, then there would be problems.)

The main question is, how do you do a *reliable* self-check, that also
does not prevent the user's ability to *reasonably* customize the
software, perhaps to do things you couldn't even have considered.
(making the reasonable assumption that not every piece of
software gets updated ad infinitum...)

It strikes me as a real dilemma.  I look forward to proposed solutions.
--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



- -------------------------

From: [e-mail] (Juri Munkki)
Subject:  Self-checking for virii
Date: 22 Feb 92 21:43:51 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>You may not want to perform an extensive check all the time, maybe
>check parts at random so they don't slow your startup time too much.
>Also maybe perform checks when you have some idle time.

Checking for resource integrity when you have idle time is a very
bad idea on the PowerBooks. I would hate to have an application
that accesses the hard disk when it doesn't need to.

Performing random checks on startup could be ok. Personally, I don't
believe that applications should perform checks at all. I like doing
binary patches to programs and I think that virus checks would get
in the way all too often.

I haven't had a virus in my system in a few years. The disinfectant
init provides just the amount of protection that I feel that I need.
Of course, I don't download all that much software.

The Macintosh virus scene has been very quiet in the recent years. I
hope it stays that way. I remember when nVir was new and PC users were
telling me how DOS was so simple that there wasn't much room for a
virus to work in... It seems to me that they ended up having a lot
more trouble than the Mac users.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



- -------------------------

From: [e-mail] (Christopher Tate)
Subject:  Self-checking for virii
Date: 22 Feb 92 21:54:27 GMT
Organization: Penn State University

In article <[e-mail]>, [e-mail]
(Jonathan Greenfield) says:
>
>The only problem with these various techniques is that a *user* may
>*legitmately* change resource in order to customize the software.  In
>fact, one might legitimately *add* resources.  (An outdated example,
>one might add 'mstr', etc. resources to facilitate pulling "puppet
>strings" on older applications.  If these old apps had done such
>virus checking, then there would be problems.)
>
>The main question is, how do you do a *reliable* self-check, that also
>does not prevent the user's ability to *reasonably* customize the
>software, perhaps to do things you couldn't even have considered.
>(making the reasonable assumption that not every piece of
>software gets updated ad infinitum...)
>
>It strikes me as a real dilemma.  I look forward to proposed solutions.

Proposed Solution #1:
- ------------------

Rather than checksumming the entire resource fork, checksum only those
resources which are executable code.  Presumably, these resources should
NOT change, EVER, and you don't have problems with people customizing
the menus or what have you.

The disadvantage is that it's slower than just using OpenRF to read the
entire resource fork.

Another consideration is the addition of resources which shouldn't be
there, such as MBDF's, WDEF's, etc.  It seems to me that checking for
the existence of such unwanted extra code would be the hard part, since
it's very difficult to predict just what vector a new virus would use
for infection.

And, to top it all off, you want to avoid having to parse the resource
map, since it's Subject To Change Without Notice.

A tricky problem, indeed....  Not hard to do in principle, but rather
difficult to do in a *friendly* manner.

- -----
Christopher Tate                 |  Cryptogram #10:
[e-mail]             |
[e-mail]              |  EF'Z J ZBSWMECG FTBDGTF FTJF ITWC
- -------------------------------|  KBYJMF IJZ KL JGW, TW IJZ XWJX QBM
Send me the answer, I love mail! |  FIB LWJMZ.  (FBK UWTMWM)



- -------------------------

From: [e-mail] (Peter N Lewis)
Subject:  Self-checking for virii
Organization: NCRPDA, Curtin University
Date: Sun, 23 Feb 1992 02:28:36 GMT

In article <[e-mail]>, [e-mail] (Christopher Tate) writes:
>
> In article <[e-mail]>, [e-mail]
> (Jonathan Greenfield) says:
> >
> >The only problem with these various techniques is that a *user* may
> >*legitmately* change resource in order to customize the software.  In
> >fact, one might legitimately *add* resources.  (An outdated example,
> >one might add 'mstr', etc. resources to facilitate pulling "puppet
> >strings" on older applications.  If these old apps had done such
> >virus checking, then there would be problems.)
>
> Proposed Solution #1:
> --------------------
Amendment 1 :-)

> Rather than checksumming the entire resource fork, checksum only those
> resources which are executable code.  Presumably, these resources should
> NOT change, EVER, and you don't have problems with people customizing
> the menus or what have you.

Thats not true.  I was patching the CODE resources in THINK Pascal just
yesterday.  There are several reasons to patch CODE resources, usually
to remove a function you don't like (such as beeping, or displaying
an annoying alert (no, not pirating, boy you people are paranoid!)).

> Another consideration is the addition of resources which shouldn't be
> there, such as MBDF's, WDEF's, etc.  It seems to me that checking for
> the existence of such unwanted extra code would be the hard part, since
> it's very difficult to predict just what vector a new virus would use
> for infection.

Seems to me a good start would be to create a resource that holds:
The number of resources of each kind (basically your own psuedo copy of
the resource map), and there ids and sizes.  The when you build your
application, set this resource up in an obviously defunct manner (say
no resources at all), and so just rebuild it from thge current  resource
file.  Otherwise, verify its accuracy, and if it fails TELL the user
that the file has been modify, and ASK them if they did it.  If so,
rebuild the resource info.

If you just refuse to run, then after I patch the binaries I'm going to
have to go fiund the "virus" checking code and patch that too - what a pain!

How's that sound?
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]





- -------------------------

From: [e-mail]
Subject:  Self-checking for virii
Date: 22 Feb 92 21:45:54 CST
Organization: University of Kansas Academic Computing Services

In article <[e-mail]>, [e-mail] (Daryl Spitzer) writes:
> How would one go about writing code in an application that would self-check for
> a virus?  I guess one could do a CRC check on the resource fork...and the CRC
> could be stored in the data fork (so the CRC wouldn't be included in
> itself)...would this work?
> --
> -------------------------------------------------------------------
>  [e-mail]     "Life isn't just, life just is."
>          [e-mail]              -- Me  (I think.)
>        [e-mail]
> -------------------------------------------------------------------

I believe it's much simpler than that - I understand it's merely a matter of
counting your resources.  I had thought before this that I could merely check
the size of all my CODE resources, but it looks like checking for *additional*
resources is required (although an additional CODE resource was an obvious one
that didn't occur to me either).  Although, checking the size of the resources
is probably still a good idea.

Another reason why I see I shouldn't be saving *any* data into my programs own
resoure fork - it just makes the self-check all the trickier.

john calhoun-




- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Self-checking for virii
Organization: CIS Dept., Syracuse University
Date: Sun, 23 Feb 92 09:42:51 EST

In article <[e-mail]> [e-mail] (Peter N Lewis) writes:

>> >The only problem with these various techniques is that a *user* may
>> >*legitmately* change resource in order to customize the software.  In
>> >fact, one might legitimately *add* resources.  (An outdated example,
>> >one might add 'mstr', etc. resources to facilitate pulling "puppet
>> >strings" on older applications.  If these old apps had done such
>> >virus checking, then there would be problems.)
>
>Seems to me a good start would be to create a resource that holds:
>The number of resources of each kind (basically your own psuedo copy of
>the resource map), and there ids and sizes.  The when you build your
>application, set this resource up in an obviously defunct manner (say
>no resources at all), and so just rebuild it from thge current  resource
>file.  Otherwise, verify its accuracy, and if it fails TELL the user
>that the file has been modify, and ASK them if they did it.  If so,
>rebuild the resource info.

I like the basic idea here.  Set up *some* kind of integrity check, and if
there is a problem, then alert the user and find out whether the change
was made by the user.  If it was, then readjust the integrity parameters
(used for the check), so that any future changes will also be detected.

Sounds to me like the best of both worlds--reasonable virus protection, and
support for user customization.
--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



- -------------------------

From: [e-mail]
Subject:  Self-checking for virii
Date: 24 Feb 92 07:41:07 GMT
Organization: University of Otago, Dunedin, New Zealand

In article <[e-mail]>, [e-mail] (Peter N Lewis) writes:
> In article <[e-mail]>, [e-mail] (Christopher Tate) writes:
>>
>> Rather than checksumming the entire resource fork, checksum only those
>> resources which are executable code.  Presumably, these resources should
>> NOT change, EVER, and you don't have problems with people customizing
>> the menus or what have you.
>
> Thats not true.  I was patching the CODE resources in THINK Pascal just
> yesterday.  There are several reasons to patch CODE resources, usually
> to remove a function you don't like (such as beeping, or displaying
> an annoying alert (no, not pirating, boy you people are paranoid!)).
>

I'm afraid there are more serious problems than that. Consider the fact that
the new version of SANE in Systm 7.0.1 and later patches the floating-point
calls in your code at runtime as it comes through the segment loader. Guess
what will happen to your checksum computed on the disk version when you compare
it with the resource in memory. And no, you can't make it load a fresh copy
from disk, the Resource Manager already has it and insists that you take it...

Another code patcher that is virtually indistiguishable from a virus is
FileGuard, which has a very handy application protection facility which works
by modifying the application with CODE that insists that it remain on the same
hard disk. I myself have written a security system that we have been using for
several years that does this. It works just fine, except for Claris
applications where I have to go in and patch their virus alert to say "Sorry,
please ignore this alert" :-(.



Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

SCREMBY (n.)
The dehydrated felt-tip pen attached by a string to the `Don't Forget'
board in the kitchen which has never worked in living memory but which no
one can be bothered to throw away.



- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Subject:  Self-checking for virii
Date: 25 Feb 92 01:00:58 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] writes:
>
> In article <[e-mail]>, [e-mail] (Peter N Lewis) writes:
> >
> > Thats not true.  I was patching the CODE resources in THINK Pascal just
> > yesterday.  There are several reasons to patch CODE resources, usually
> > to remove a function you don't like (such as beeping, or displaying
> > an annoying alert (no, not pirating, boy you people are paranoid!)).
> >
>
> I'm afraid there are more serious problems than that. Consider the fact that
> the new version of SANE in Systm 7.0.1 and later patches the floating-point
> calls in your code at runtime as it comes through the segment loader. Guess
> what will happen to your checksum computed on the disk version when you compare
> it with the resource in memory. And no, you can't make it load a fresh copy
> from disk, the Resource Manager already has it and insists that you take it...

If the new SANE is anything like Omega SANE then it patches the code when
you execute the SANE trap not when the segment is loaded.  Thus your code
would not be modified until you do some SANE calls.  One would assume that
you can organise to do your anti-virus checksum before you make any SANE
calls.

Quinn "The Eskimo!"   <[e-mail]>   "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia



- -------------------------

From: [e-mail] (Ken McLeod)
Subject:  Self-checking for virii
Date: 25 Feb 92 06:52:23 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Michael Peirce) writes:
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Daryl Spitzer) writes:
> >
> > How would one go about writing code in an application that would self-check for
> > a virus?  I guess one could do a CRC check on the resource fork...and the CRC
> > could be stored in the data fork (so the CRC wouldn't be included in
> > itself)...would this work?
> ...
> to work well.  Checksum your code (any code resources your program
> uses CODE, WDEF, MDEF, etc).  Look for new resources that shouldn't
> be there.  Check the size of resources that sould stay constant.

 One major problem to be aware of, if you're thinking about checksumming your
CODE resources to determine their integrity: system software may actually
modify your code at runtime! A prime example is OmegaSANE (built into System
7.0.1), which backpatches _FP68K trap calls into JSR's on the fly. Checking
the size and number of resources is less thorough than a CRC, but probably a
better strategy for compatibility with future system "enhancements".

-ken
been there, got bit

--
Ken McLeod
Support Technologies Group
Apple Computer, Inc.
AppleLink: THE.CLOUD  Internet: [e-mail]



- -------------------------

From: [e-mail] (Robert J Woodhead)
Subject:  Self-checking for virii
Date: 28 Feb 92 02:33:19 GMT
Organization: Foretune Co., Ltd.

[e-mail] (Ken McLeod) writes:
> One major problem to be aware of, if you're thinking about checksumming your
>CODE resources to determine their integrity: system software may actually
>modify your code at runtime! A prime example is OmegaSANE (built into System
>7.0.1), which backpatches _FP68K trap calls into JSR's on the fly. Checking
>the size and number of resources is less thorough than a CRC, but probably a
>better strategy for compatibility with future system "enhancements".

OmegaSANE does not modify a _FP68k trap until the trap is actually called.
Therefore, if you do your code integrity checking _before_ the code
being checked has been executed, you should be ok.  If you want to be
paranoid, do your checking in your initial segment, and do a different
check for that segment (less rigorous) and a more rigorous check of
as-yet unexecuted segments.

That being said:

Apple's decision to allow system software to modify user programs on
the fly is, IMHO, _EXTREMELY ILL ADVISED_.  Especially since it can
cause software to break if the existing software jumps directly to
a _FP68K trap and not to the previous MOVE instruction.  Anyone who
wants real speed in FPU ops either gets the trap address or goes
directly to the FPU.  If Apple wants to specify a faster but more
complicated way of accessing SANE (such as a call that gives us the
ROM addresses), fine.  But keepa your handsa offa my code!

--
+---------------------------------------------------------------------------+
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.    [e-mail] |
| "9/13/99 : First nuclear explosion on the far side of the moon"           |
|     --- One of the many headlines in Gainax's "Otaku no Video 1985"       |



---------------------------

From: [e-mail] (Benjamin T Sander)
Subject: New Trap Patch Questions
Organization: University of Illinois at Urbana
Date: Sat, 22 Feb 1992 08:30:14 GMT

I am trying to patch HGetVInfo, which has trap number $A207.  Problem is,
it has the same dispatch vector as getVolInfo ($A007).  Is there any
way I can tell which trap called me inside of my patch?

Is the last trap called by the system stored anywhere in memory?

How do the HFS calls tell the difference?

Thanks,

Ben Sander




- -------------------------

From: [e-mail] (Michael Kahl)
Subject:  New Trap Patch Questions
Date: 23 Feb 92 02:12:53 GMT
Organization: Enginuity Inc.

In article <[e-mail]> [e-mail] (Benjamin T Sander) writes:
>I am trying to patch HGetVInfo, which has trap number $A207.  Problem is,
>it has the same dispatch vector as getVolInfo ($A007).  Is there any
>way I can tell which trap called me inside of my patch?
>
>Is the last trap called by the system stored anywhere in memory?
>
>How do the HFS calls tell the difference?

This can be done for register-based traps only (of which the trap in question
is one).

On entry to such traps, the low word of register D1 contains the trap word.  So
to distinguish between _GetVolInfo and _HGetVInfo, you would do:

    BTST  #9,D1

By the way, this D1 stuff is important to know if you ever *patch* a register
based trap:  it is important to restore D1 before chaining on to the real trap.

--
Michael Kahl, Software Architect, Enginuity Inc.
[e-mail]  -or-  [e-mail]
Disclaimer:  Whoa!  Did I say THAT??!



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  New Trap Patch Questions
Date: 25 Feb 92 03:51:43 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Benjamin T Sander) writes:
>I am trying to patch HGetVInfo, which has trap number $A207.  Problem is,
>it has the same dispatch vector as getVolInfo ($A007).  Is there any
>way I can tell which trap called me inside of my patch?
>
>Is the last trap called by the system stored anywhere in memory?
>
>How do the HFS calls tell the difference?

I believe that for OS traps, the trap number is left in one of the
registers (D1, I think). You can check this yourself with a debugger.
Or, since the stack pointer points to the return address, you can use
that to get a pointer to the A-Trap instruction and retrieve the
trapword yourself.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Dean Yu)
Subject:  New Trap Patch Questions
Date: 26 Feb 92 18:14:24 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Benjamin T Sander) writes:
>
> I am trying to patch HGetVInfo, which has trap number $A207.  Problem is,
> it has the same dispatch vector as getVolInfo ($A007).  Is there any
> way I can tell which trap called me inside of my patch?
>
> Is the last trap called by the system stored anywhere in memory?
>
> How do the HFS calls tell the difference?
>
> Thanks,
>
> Ben Sander

  For OS traps, the trap word will be in the low word of D1 upon entry
to the routine.  You can look at this to determine whether the
H bit is set.  This is how things are now, but as always, it might
change in the future.

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.



---------------------------

From: [e-mail] (Dan Connolly)
Subject: smallest unit of RTF
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Tue, 25 Feb 1992 00:26:30 GMT

Broad question: what do you folks (formatted text application developers)
use as a reference for the Rich Text Format?

Specific question: what's the minimum content of a piece of Rich Text?
In other words: it's fairly clear what makes a legal Rich Text document,
but what makes a legal rich text "chunk" or "selection" or "run?"

Is this a legal "chunk" of rich text:

{\rtf1\ansi\deff0{\fonttbl{\f0\fmodern Courier;}}\pard\plain Hello World.\par}

how about this:
\pard \plain Hello World.\par

or this:
Hello World.

or this:
Hello \bWorld.
or this:
Hello \bWorld.}
or:
Hello {\bWorld.}

Dan




- -------------------------

From: [e-mail]
Subject:  smallest unit of RTF
Date: 26 Feb 92 02:33:14 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Dan Connolly) writes:
> Broad question: what do you folks (formatted text application developers)
> use as a reference for the Rich Text Format?

I just see what MS Word will generate or accept :-)


> Specific question: what's the minimum content of a piece of Rich Text?

A little experimentation shows that...

{\rtf1 Hello \b World.}

... is the least that Word 4 will accept in a text file (and offer to parse
as rtf).  You should be able to experiment with rtf resources in the clipboard
yourself.

--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  smallest unit of RTF
Date: 26 Feb 92 19:43:45 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

>> Specific question: what's the minimum content of a piece of Rich Text?
>
>A little experimentation shows that...
>
>{\rtf1 Hello \b World.}
>
>... is the least that Word 4 will accept in a text file (and offer to parse
>as rtf).  You should be able to experiment with rtf resources in the clipboard
>yourself.

Yes.  My copy of Word 4 uses Times 12 for the font.  My own RTF
reader uses Chicago 12, after complaining that it couldn't find
font one in the font table (there is no font table).  Why
Chicago?  Well, without a font table, I assume that the Mac has a
system font, font 0.  Perhaps it isn't Chicago for non-US
systems...  but it should still be a font.  Why 12?  I can't
remember.  Maybe it is in the RTF spec.

Stephen.



- -------------------------

From: [e-mail] (Stephan - Somogyi)
Subject:  smallest unit of RTF
Date: 28 Feb 92 00:21:04 GMT
Organization: The Portal System (TM)

[e-mail] writes:

>I just see what MS Word will generate or accept :-)

This, unfortunately, will not work any more. Microsoft changed the RTF
format in Word 5 for "better PC compatibility." A Word 5-generated RTF
file is not usable completely by Word 4 since, for example, smart
single and double quotes don't travel.

W4 ignores RTF tokens it doesn't know about and W5 has defined
specific new tokens for many characters instead of using the explicit
numeric ASCII value.

PageMaker's RTF import filter also doesn't like W5's RTF, however I'm
certain that they're working on that.

_____________________________________________________________________
Stephan Somogyi                                               MacUser



---------------------------

From: [e-mail]
Subject: AppleTalk Program Question
Date: 23 Feb 92 06:31:06 GMT

Can someone briefly explain to me why it is that some programs can
accessed at the same time on an AppleTalk network and other programs
will not allow you to do so (you get a message saying that the file
or program is in use).  Is it difficult to design a program that can
be accessed my multiple users?

If you could send replies to my address I'd appreciate it as I do
not get regular feeds from this newsgroup. Thanks a bunch!
([e-mail])

_____
|...........\
|.............\
|...............\____________________
|........Kevin Kurtz...........................|.........\
|........Mariana Elementary.............|_____\__
|........Apple Valley, CA.......................................)
|[e-mail].....................)
|_______________________________/
        ///////////////
        ////////////
        /////////
        ///////
        ////



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  AppleTalk Program Question
Date: 25 Feb 92 10:35:00 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] writes:

   Can someone briefly explain to me why it is that some programs can
   accessed at the same time on an AppleTalk network and other programs
   will not allow you to do so (you get a message saying that the file
   or program is in use).  Is it difficult to design a program that can
   be accessed my multiple users?

No, it's just sloppy programmers that modify their application's
resource for (or data fork) that won't share well. Try turning the
"shared" bit on in ResEdit; many programs actually CAN share, but
hasn't got this bit set so the finder won't let it.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



---------------------------

From: [e-mail] (Denis Bohm)
Subject: Are there any c++ compilers for the Mac?
Date: 25 Feb 92 20:48:38 GMT
Organization: DSG, Stanford University

Are there any c++ compilers for the Mac?  I am looking for one that
runs on the mac OS, not unix...
--
Denis Bohm ([e-mail] -or- [e-mail])



- -------------------------

From: [e-mail] (Jeff J Barczewski 52824)
Subject:  Are there any c++ compilers for the Mac?
Date: 28 Feb 92 19:02:38 GMT
Organization: Air Force Institute of Technology

[e-mail] (Denis Bohm) writes:

>Are there any c++ compilers for the Mac?  I am looking for one that
>runs on the mac OS, not unix...
>--
>Denis Bohm ([e-mail] -or- [e-mail])

Symantec offers Zortech C++ and Apple has its own MPW C++. Note the
Zortech one is a globally optimizing compiler versus Apple's cfront
translator.
                          Jeff SkI



---------------------------

From: [e-mail] (Danny McCampbell)
Subject: Simple Program...help?
Date: 25 Feb 92 21:12:19 GMT
Organization: University of Tennessee

I have been asked to write a simple program that does nothing more that display
a dialog at startup and will not continue until the user clicks OK.  I do not
want this program to run as a startup application under system seven.  I would
like it to be an extension.  I have never written anything but stand along
applications.  Could someone please send me some sample code(in THINK Pascal)
that was used as an extension.  I just need to know how to get started, etc.
Thanks.

Danny

Also, how hard is it to modify the driver of a hard disk not to show the HD
icon on the desktop when a user boots from a floppy?  Or is there an easier way
to achieve this?



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  Simple Program...help?
Date: 27 Feb 92 03:28:14 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Danny McCampbell) writes:
>Also, how hard is it to modify the driver of a hard disk not to show the HD
>icon on the desktop when a user boots from a floppy?  Or is there an easier way
>to achieve this?

Really hard since the hard disk driver isn't responsible for drawing its icon
on the desktop.  From that angle, the best you could do would be to make the
icon "clear", but the Finder will still draw the HD's name.

The other way, of course, is to muck with the Finder, but _I_ wouldn't do
that...

steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



- -------------------------

From: [e-mail] (REDMAND CHRISTOPHER M)
Subject:  Simple Program...help?
Date: 28 Feb 92 03:07:32 GMT
Organization: University of Colorado, Boulder

[e-mail] (Steve Christensen) writes:

>[e-mail] (Danny McCampbell) writes:
>>Also, how hard is it to modify the driver of a hard disk not to show the HD
>>icon on the desktop when a user boots from a floppy?  Or is there an easier way
>>to achieve this?

>Really hard since the hard disk driver isn't responsible for drawing its icon
>on the desktop.  From that angle, the best you could do would be to make the
>icon "clear", but the Finder will still draw the HD's name.

Not necessarily ... it depends on whether or not you want it to be totally
inaccessible or just hidden from the finder.  If you want total transparency,
there are at least hard disk utilities that can provide this by acting as
though the hard disk were unformatted.  La Cie has a package that does this,
I don't know about anyone else.

Now if you want to have access to the disk, but just keep it hidden, that's
really hard.

    - Chris



---------------------------

From: [e-mail] (opcode ranger)
Subject: Preference Files/Folders: How to do under 6.x?
Date: 26 Feb 92 01:07:58 GMT

Does anyone out there have any sample code for creating a preferences file in
the preferences folder  under System 6.x -- or can they point me to some?  (The
code will go in a commercial project, so it needs to be free o' strings).

I believe that in order to find the pref folder under 6.x I would go to the
blessed folder and do something like PBGetCatInfo() with the directory name of
"Preferences", right?

OK, but if I need to create pref file in this folder, what's the best way to do
it? (I know I also need to check to see if it's in the blessed folder itself
first).  This sounds like another one of those situations where I'm going to
have to create a working directory, something I Really Don't Want To Do.

Is there any sample code from Apple on this?  I checked the snippets, but saw
none.

On a related note, what's the Correct Thing to do with regard to keeping
pref files open: keep them open as long as your app is open, writing to them
when necessary, or only opening, writing, and closing them every time you need
to write to them?

Any info much appreciated!

Robert


--
==============================================================================
= [e-mail] * "Out there on a darkened road, the lights =
= are dead and the cars explode" -- "Good Things", Sisters of Mercy           =
==============================================================================



- -------------------------

From: [e-mail] (Peter N Lewis)
Subject:  Preference Files/Folders: How to do under 6.x?
Organization: NCRPDA, Curtin University
Date: Wed, 26 Feb 1992 07:01:42 GMT

In article <[e-mail]>, [e-mail] (opcode ranger) writes:

> Does anyone out there have any sample code for creating a preferences file in
> the preferences folder  under System 6.x -- or can they point me to some?  (The
> code will go in a commercial project, so it needs to be free o' strings).

 procedure GetPrefsFSSpec (var fs: FSSpec);
  var
   gv: longInt;
   oe: OSErr;
   pb: HParamBlockRec;
   sysenv: SysEnvRec;
   s: str255;
   dummy: longInt;
 begin
  if (Gestalt(gestaltFindFolderAttr, gv) <> noErr) |
     (not BTST(gv, gestaltFindFolderPresent)) |
     (FindFolder(kOnSystemDisk, kPreferencesFolderType, kCreateFolder, fs.vRefNum, fs.parID) <> NoErr) then begin
   oe := SysEnvirons(1, sysenv);
   with pb do begin
    fs.vRefNum := sysenv.sysVRefNum;
    GetIndString(s, prefsStrhResID, prefsFolderNameStrhIndex);
    if DirCreate(sysenv.sysVRefNum, 0, s, fs.parID) <> noErr then begin
     ioNamePtr := @s;
     ioVRefNum := fs.vRefNum;
     ioFDirIndex := 0;
     ioDirID := 0;
     if (PBGetCatInfo(@pb, false) = noErr) & (BAND(ioFlAttrib, $0010) <> 0) then
      fs.parID := pb.ioDirID
     else
      fs.parID := 0;
    end;
   end;
  end;
  GetIndString(s, prefsStrhResID, prefsNameStrhIndex);
  fs.name := s;
 end;

Where STR# id prefsStrResID has two strings, normally
Preferences             <the folder name for System 6>
MyApp Preferences       <the prefs file name>

For System 6, there is no way to tell the nationalized name for the prefs
file, so you just have to either internationalize your app, or leave it
to the user to change.  Alternatively you could not do the DirCreate,
and simple leave the FSSpec with the sysVRefNum out of then sysenvirons
call, and a dirID of 0.  I prefer the former (obviously, thats what
my code does :-), which makes System 6 behave as closely to System 7
as possible.

HTH,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]





- -------------------------

From: [e-mail] (Nigel Stanger)
Subject:  Preference Files/Folders: How to do under 6.x?
Date: 26 Feb 92 20:23:42 GMT
Organization: University of Otago, Dunedin, New Zealand

In article <[e-mail]>,
[e-mail] (opcode ranger) writes:
[...]
> On a related note, what's the Correct Thing to do with regard to keeping
> pref files open: keep them open as long as your app is open, writing to them
> when necessary, or only opening, writing, and closing them every time you
> need to write to them?

I don't know about the Correct Thing, but I use the second
approach. I display the Prefs dialog, the user makes all their
changes, and when they hit OK, I open the Prefs file, save out
the changes, then close it again. It probably depends on how
often you expect people to change the prefs - in my case probably
not very often, but your mileage may vary.

--
See ya
                                Nigel.
- --------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
"Oh, a SCYTHE!!" -- Edmund Blackadder, "Blackadder II"



- -------------------------

From: [e-mail] (opcode ranger)
Subject:  Preference Files/Folders: How to do under 6.x?
Date: 26 Feb 92 21:32:50 GMT

In article <[e-mail]>, I wrote:
[...]
>  This sounds like another one of those situations where I'm going to
> have to create a working directory, something I Really Don't Want To Do.


Wrong!  As someone quite correctly pointed out to me, there are numerous HFS
calls under 6.x that I can take advantage of, something I had forgotten (it's
amazing what you forget when you take a couple of months off from hacking :->).

Robert


--
==============================================================================
= [e-mail] * "Out there on a darkened road, the lights =
= are dead and the cars explode" -- "Good Things", Sisters of Mercy           =
==============================================================================



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  Preference Files/Folders: How to do under 6.x?
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 27 Feb 1992 20:33:04 GMT

[e-mail] (Nigel Stanger) writes:
>approach. I display the Prefs dialog, the user makes all their
>changes, and when they hit OK, I open the Prefs file, save out
>the changes, then close it again.

Eudora keeps her settings file open all the time.  Settings are kept
in a resource, and having the settings file open means it's always at
the top of the resource chain.  This has the benefit of allowing users
to override resources in Eudora by putting resources in the settings
file.

What's nice about putting these resources in the settings file is that
a) they don't affect other users, like they would if users editted the
app directly and b) users don't lose their customizations when they upgrade
to the next version of Eudora.

I'm really happy with the way it has worked out.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner



---------------------------

End of C.S.M.P. Digest
**********************